Mainframes have grown up with dumb terminals as the primary way to access system functionality. There has been a growth of newer devices, such as personal computers with graphical user interface (GUI) operating systems, mobile devices such as smart phones and tablets, or mashup devices used in situational applications. Providing a way to drive the mainframe through these heterogeneous client devices, as well as future form factors such as mobile and touch devices, is key to continued existence and relevance of the mainframe.
The legacy of 45 years of functionality in mainframes means that there are hundreds of commands which are already proven, reliable and trusted to perform tasks, such as, start address spaces, query system information, or respond to system events. A solution is required which unlocks the commands to access through any client device, without incurring the overhead that comes through explicit client/server boundary configuration or coupling.
The IBM® 3270 (IBM is a trade mark of International Business Machines Corporation, registered in many jurisdictions worldwide) is a class of block oriented terminals made by IBM since 1972 (known as “display devices”) normally used to communicate with IBM mainframes.
Current implementations either use IBM 3270 interfaces or a server component incurring problems described below.
The client implements an IBM 3270 data stream, or screen scrapes an IBM 3270 terminal emulator and uses that session to issue the commands.
Drawbacks:
(A) The user's user id is required to log into the system, meaning that the user id could not be used separately to log into the system. This means that if the user is logged into a separate 3270 session then either they will be logged off that session, or the client will be unable to issue the commands, making them less productive. Current work-arounds require the creation of multiple user ids which has a cost overhead and is less flexible.
(B) Interpreting and responding to a 3270 data stream requires significant logic. This means any such implementation is costly to develop, test and maintain.
(C) Screen scraping adds to complexity and requires a coupling between the client code and the server 3270 panels. If the panels change without modifications to the client, then the application fails. This problem makes this approach brittle, difficult to maintain and unreliable.
In server stored programs, the client sends Job Control Language (JCL) that executes a stored program with command(s) passed in the JCL. Job Control Language (JCL) is a scripting language used on mainframe operating systems to instruct the system on how to run a batch job or start a subsystem.
Drawbacks:
(D) This approach requires one or more programs to be pre-installed on the server. This introduces cost and complexity of configuration and restricts the ability of the client to attach to any server and execute commands.
(E) Any maintenance changes may have to be applied to both the client and all targeted servers. This introduces cost and complexity of configuration.
(F) Server configuration changes are closely controlled and managed by system administrators and often constrained to fixed maintenance windows. This means that updates are delayed and incur a higher deployment cost.
Therefore, there is a need in the art to address the aforementioned problems.